Conversation
Having all groups deployable could be a big effort for large multisite systems. This will help manage large systems avoiding big changes in database if changes were made.
|
Hi @calien666 , thanks for PR, can you explain the use case? (i don't see it) |
|
Hi @achimfritz, Had to check, what I've done here. As far as I understood, there is no possibility making a fine granulated permission set per user. With permissions set for user, there would be the possibility skipping a database record for the group and directly access the set to the user, which has big advantages in multi domain instances and managing all permissions only per set and not inside the database. This makes the be_groups partially obsolete and avoids a huge list of backend groups in the database. At the moment wer'e hosting a system, which has a pre-defined set of access permissions, which needs an adjustment for at least 11 groups per website inside the backend, having 4 of them directly accessed to backend users. With at least over 350 Websites multiplied by four groups, this leads us to about 1500 database groups needed for adding group permissions to the backend users. Having the possibility of a direct access to the permission sets inside the backend user instead of the group will decrease database groups massively and help us maintain sets with versioning. |
|
I think this is not the (our?) common way, and this change should not go into this extension |
350 websites in one installation sounds a lot to me. Does that work well? Back in TYPO3 7-ish we split a large installation into separate ones because of performance issues. Back to topic: I understand this reduces backend groups, but is it really easier to update the users instead? To me, ensuring that group permissions are correct seems easier to do and validate. Applying them directly to the user sounds like people may easily forget some settings when creating new users. |
|
@saitho We don't have any issues in speed or performance. I maintained even bigger systems with up to 1200 domains inside one TYPO3 without any issues. The bigger system only used a Varnish Cache in front of the TYPO3 with Apache2 webserver. Our 350 domain system currently only uses caching mechanisms from nginx and TYPO3, but most related cache is not stored inside the MariaDB, which causes issues, if you do so. Instead we use redis caching for pages and contents and smaller parts are directly served by the Solr search server (especially the event listing). |
Having all groups deployable could be a big effort for large multisite systems. This will help manage large systems avoiding big changes in database if changes were made.